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HANDLING PARAMETERS IN BLOCK DIAGRAM MODELING 

BACKGROUND 

The invention relates to handling parameters in block diagram modeling. 

Dynamic systems may be modeled, simulated and analyzed on a computer system 
5 using graphical block diagram modeling tools, e.g., Simulink® from The Math Works Inc. 
Graphical block diagram modeling graphically depicts mathematical relationships among a 
system's inputs, states, parameters, and outputs, typically through the use of graphical user 
interface. 

In a graphical context, a block diagram is a directed graph containing nodes and arcs 

10 providing a means by which the nodes can communicate. In most block diagramming 

paradigms, the nodes are referred to as blocks and dravra using some for of geometric object 
(e.g., circle, rectangle, etc.) and the arcs are typically drawn using line segments connecting 
the geometric objects. These line segments are often referred to as signals. For example, 
some Simulink® block diagrams enable the user to model dynamic systems where each 

15 block represents a functional entity that mathematical operations and transformations on the 
data (variables) being processed by a system and therefore implements a set of equations. 
The signals represent a time-varying quantity that is updated, i.e., read-by and written-to, by 
the blocks. Within Simulink®, blocks execute using a predetermined ordering and with 
control-flow semantics. Other types of graphical block diagrams include data-flow block 

20 diagrams wherein blocks wait for data to be valid before they execute. 

Within Simulink®, executing a graphical block diagram model refers to solving the 
equations defined by the nodes in the directed graph. The order of execution of the nodes is 
dictated by the direction of the arcs that connect the nodes. Graphs with strongly connected 
components (i.e., nodes that form cycles) can be executed by solving each cycle 

25 simultaneously as a coupled set of equations. 

In theory, there can be a number of equations (often referred to as block methods) that 
are associated with a block. For example, Simulink® supports various types of block 
methods. One such block method is an output method, expressed in the form of 

30 y = OutputMethod (t, X, u, p) 
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where y is typically a set of block output signals (or some other forms of output, e.g., a 
logging device such as a plotting tool or a data archiving block), t is time, x represents a set 
of continuous states and discrete states, u represents the set of input signals to the block and 
p represents a set of parameters supplied to the block. 

A user can parameterize a block with user-defined values by specifying the 
parameters p that are to be used by the block. For example, Simulink® allows a user to 
specify block parameters through a dialog box or programmatically via a 'set_param' 
command. 

As indicated earlier, a parameter can take on a wide variety of attributes. In addition, 
a parameter can be defined as an expression. For example, for a gain block that has an output 
method y=p^u , where p represents a single parameter, a user could define the parameter p 
as a numeric quantity (e.g., 1 : 1 0), an expression of variables and functions, e.g., 
a*b+sin(c), ora combination of the two. 

Using the equations defined by the blocks, block diagrams can be executed in an 
interpreted environment that produces a simulation result as defined by the blocks and 
signals in the model. In addition, code can be generated from the block diagrams and 
executed in an executive. The executive is often referred to as an execution framework for 
the generated code. It is responsible for executing the generated code by calling the entry 
points in the generated code at the right times. 

SUMMARY 

In one aspect, the invention provides methods and apparatus, including computer 
program products, for manipulating graphical block diagram block parameters in a graphical 
block diagram modeling environment. The methods include receiving a graphical block 
diagram of blocks for a model developed by a user and processing parameters specified for 
each of the blocks by the user to produce run-time parameters. 

Particular implementations of the invention may provide one or more of the following 
advantages. 

The parameter processing mechanism provides the ability to create optimized 
equations that use specific run-time parameter configurations derived from the dialog 
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parameters entered by the user. For example, the parameter pooHng makes optimal use of 
the constant data memory allocated to block parameters. Run-time parameter pooling 
achieves optimal data store (parameter data reuse) in both a simulation environment and in 
automatically generated code. 
5 In addition to the pooling of constant parameters, a block can specify that a parameter 

it is using in its equation is constant, even if that parameter is specified by a user as an 
interfaced variable. Within block diagrams, user's can explicitly designate certain variables 
as interfaced and, therefore, in this context, an interfaced variable is a variable name that has 
been specified as a parameter or part of a parameter expression. Interfaced variables can be 

10 accessed and updated during block diagram simulation or in the resulting generated code for 
the block diagram while the generated code is executing. Marking a parameter as constant 
means that the interfaced variable will not be accessible and that the parameter values will be 
pooled, thereby enabling further parameter pooling. Under this scenario, the parameter 
processing mechanism can issue a warning informing the user of the situation. 

15 The parameter processing mechanism also enables preservation of interfaced 

variables contained within parameter expressions in generated code. The ability to maintain 
the structure of parameter expressions in the generated code allows users of a block diagram 
tool to solve a larger class of problems. By maintaining the structure of expressions in this 
manner, more flexibility is afforded when a user's executive is running (calling) the 

20 generated code. The executive (execution framework) can probe and update the values of the 
interfaced variables. 

The definition of run-time parameters and mapping of user-specified parameters to 
run-time parameters enables a graphical block diagram tool to produce optimal 
implementations of the block equations for a given user supplied data set. Users can also 
25 create their own blocks with block equations optimized for run-time parameters, thus 
enabling the user of a graphical block diagram tool to extend the parameter processing 
optimizations and mappings in simulation execution or automatically generated code to 
custom blocks. 

Other features and advantages of the invention will be apparent from the following 
30 detailed description and from the claims. 



3 
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DESCRIPTION OF DRAWINGS 

FIG. 1 is a block diagram of a system that includes a file server that stores a graphical 
block diagram modeling/simulation module that includes a model editor and simulator that 
supports block diagram parameter processing and client systems that access a file server and 
execute processes of the graphical block diagram modeling/simulation module for graphical 
block diagram model development and execution. 

FIGS. 2A-B are depictions of an exemplary library of graphical blocks libraries 
provided by the graphical block diagram modeling/simulation module (of FIG. 1) and 
available for use in developing and executing a graphical block diagram model. 

FIG. 3 is an exemplary screen display from a GUI of a client system executing the 
model editor of the graphical block diagram modeling/simulation module (of FIG. 1) during 
graphical block diagram model development. 

FIG. 4 is an exemplary block parameter dialog box in which a user specifies 
parameters expressions. 

FIG. 5 is a flow diagram of the operational flow of the module shown in FIG. 1 . 

FIG. 6 is a flow diagram of the operational flow of a block diagram processing engine 
that processes block diagram block parameters specified by a user. 

FIG. 7 is a flow diagram of the operational flow of a compiler of the block diagram 
processing engine (shown in FIG. 6). 

FIG. 8 is an exemplary block data structure illustrating parameter-related aspects of 
the block. 

FIG. 9 is a flow diagram of the dialog parameter evaluation/processing step (fi^om 
FIG. 7). 

FIGS. lOA and lOB are exemplary depictions of an Abstract Syntax Tree generated 
by the dialog parameter evaluation (shown in FIG. 9). 

FIG. 11 is a flow diagram of the run-time parameters setup process (from FIG. 7) 
FIG. 12 is a flow diagram of the parameter pooling process (from FIG. 7). 
FIG. 13 is a flow diagram of the execution structure setup process (from FIG. 7). 
Like reference numerals will be used to represent like elements. 
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DETAILED DESCRIPTION 

Referring to FIG. 1, a system 10 includes client systems 12a, 12b,..,., 12k and a file 
server 14 each connected to a network 16, e.g., an Ethernet network, the Internet, or other 
type of network. Alternatively, instead of being connected to a network, the systems 12 and 
14 could be interconnected by a system bus such as Fibre Channel. Each of the client 
systems 12a, 12b, 12k includes a graphical user interface (GUI) 18a, 18b, 18k. The 
file server 14 is configured with a graphical block diagram modeling and simulation module 
20 (hereinafter, simply, "the module"), which is implemented in software. The module 20 
includes a model constructor/editor 22, as will be described later. The module further 
includes a blocks library 24 and a block diagram processing engine 26. As will be explained 
more fully below, the model editor 22, in conjunction with the library 24, is used by a client 
system user to construct and display a graphical block diagram model which visually and 
pictorially represents a dynamic system of interest to that user. The block diagram 
processing engine 26 processes the block diagram model to produce simulation results or, 
optionally, to convert the block diagram model to executable code. 

The system 10 illustrates a remote client access configuration in which the module 20 
is installed on a central file server, i.e., the file server 14, and users of the client systems 12 
access the module 20 over the network 12. In an alternative configuration, e.g., in an 
environment in which access to the library 24 is not shared by multiple users, the module 20 
could be installed on a single stand-alone or networked computer system for local user 
access. 

Each of the client systems 12a, 12b,..., 12k, includes a respective memory 30a, 
30b,. . ., 30k, for storing all or accessed portions of the module 20, as well as a respective 
CPU 28a, 28b, . . . , 28k for executing the stored portions of the module 20, the GUI 1 8 and 
other OS programs (not shovra) for controlling system hardware. Although not shovm, it will 
be understood that the systems 12 and 14 can be, in other respects, of a conventional design 
and architecture. That is, the systems 12 include conventional system I/O peripherals, e.g., 
display, mouse, keyboard and the like, for enabling user interaction with the system. The file 
server 14 includes conventional server software and hardware and thus includes the 
appropriate storage for storing the software programs of the module 20, along with OS and 
server application programs, and CPU for executing those programs. 
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For illustrative purposes, the module 20 will be described within the context of a 
Simulink® and MATLAB® based simulation environment. Simulink® and MATLAB® are 
commercial software products available from The Math Works, Inc. The Simulink® software 
package includes a number of different tools, such as special user interfaces and navigational 
5 tools, e.g., a library browser, which will be referenced in the description to follow. Further 
details of these tools and interfaces can be had with reference to available Simulink® and 
MATLAB® product documentation. It will be understood, however, that any other block 
diagram based modeling software platforms could be used such as the data-flow block 
diagram paradigm. 

10 The module 20 enables users to copy graphical blocks into their models from the 

libraries 24 (or, optionally, from external libraries). Alternatively, or in addition, the module 
20 allows a user to implement a custom (user-defined) block for use in a model and to add 
that custom block to the library 24 if the user so chooses. In a Simulink® product context, 
the custom, i.e., user written, blocks are known as "S-ftmction blocks". 

15 FIGS. 2A-2B provide screen shot depictions of an exemplary embodiment of the 

library 24 as a Simulink® library as presented in a window of a Simulink® library browser 
40. As shown in FIG. 2A, the library 24 is a collection of libraries 42 each corresponding to 
different groupings or categories of blocks. It will be appreciated that the libraries are 
represented within the context of the library browser's tree structure as nodes or icons. As 

20 shovra in FIG. 2B, each library 42 includes a set of one or more blocks 44. In the particular 
example shown in FIG. 2B, a user has selected a "sources" library, which includes among the 
members of its set of graphical source blocks the graphical blocks "pulse generator", "ramp", 
"random number", "repeating sequence", "signal generator", "sine wave", "step" and 
"uniform random number". These blocks all represent signal generator fiinctionality and are 

25 therefore grouped together in the sources library. Thus, a user operating one of the client 
systems 12 uses the blocks 44, for example, the sine wave block, to build a graphical block 
diagram using the model editor 22. 

A user selects blocks using a menu provided by the library browser 40. Having 
opened a model window for a model to be generated and/or edited, the user copies the 

30 selected blocks from the library window to the model window, e.g., by selecting ("clicking 
on") a corresponding library node or icon, dragging the block from the library browser and 
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dropping it in the model window. 

FIG. 3 illustrates a Simulink ® model window 50 that displays an exemplary block 
diagram model 52 created by a user using the model editor 22. The block diagram model 52 
includes a sine wave block 54 that drives a first gain ("gainl") block 56 and a lookup table 
block 58. The gainl block 56 feeds a second gain ("gain2") block 60. The gain2 and lookup 
table blocks 60, 58, respectively, in turn provide inputs to a sum block 62, the output of 
which is provided as an input to an S-function block (S-Functionl") 64. The output of the S- 
function block 64 is provided to an outport block (Outl) 66. 

Each of the blocks in the model 50 implements a specific operation (i.e., an algorithm 
or equation). In general, the equations defined by the blocks include user specified 
parameters. As indicated above, the user-specified parameters are expressions that may be in 
the form of numerical values, variables defined as constants, interfaced variables or some 
combination thereof. An interfaced variable is a variable whose value can be changed either 
during simulation or in generated code, as will be discussed in further detail later. 

For example, the output method for the S-function block 64, in the form y=u*p, 
where output y is 'sfunl_out', input u is the output of the sum block 62 'sum_out' and 
parameter p is a parameter expression 'prmll H- (prm2-prm3)', is 'sfunl_out = prml + 
(prm2-prm3) * surti out' . The variables prml, prm2 and prm3 each are user-specified 
parameters. A pseudo code example for the entire block diagram model 52 is as follows: 

Execut ionLoop : 

sine_out = sin(t); 

gainl_out ~ sine_out gainl_paraineter ; 
gain2_out= gainl_out gain2_parameter ; 
look-up_out = sine_out look-up_paraineter ; 
sum_out = gain2_out + look-up_out; 
sfunl_out = prml -f- (prm2-prm3) * sum_out; 
t = t + step_size; 
EndExecut ionLoop ; 

The model code is written using vector notation, e.g., the gainl_out = sine_out 
. * gainl_paraineter is an element-wise operation. The use of a vectored language is 
not required, however. Other "non-vectored" languages, such as C, could also be used. For 
example, if the code for the gainl block 56 output method were to be written in a non- 
vectored language such as C, the code would look like 
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int i; 

for (i-0; i< 100; i++) { 

gainl_out[i] = sine_out[i] * gainl_parameter [ i ] ; 



where the gainl block parameter 'gainl_parameter' is assumed to have been decletred as a 
vector of 100 elements initialized to the values 1, 2, 3, 4, 5, 100. In vector notation, 
1:100 declares an array of length 100 with values 1, 2, 3, 4, 5, 100. 

The library 24 is a repository of classes that correspond to the blocks. When a 
graphical class is used in a model, it is said to be instantiated, i.e., an instance of the 
graphical class is created for use in the model. Such an instance is a link to the graphical 
class that resides in the library. Block parameters are class members that are specified when 
a user constructs a new instance of a class. Instances associated with the class have 
parameter specification interfaces that allow users to define the block parameters. On a GUI, 
such parameter specification interfaces take the form of a dialog box with various parameter 
fields. Thus, the user supplies the block parameters to the block method for the appropriate 
block through a dialog box associated with the block. Alternatively, the user can specify 
parameter values programmatically using a command (e.g., the Simulink ® 'set_param' 
command). Each block in the block diagram model 52 can have between 0 and N parameters 
that are specified by a user for use in the block methods for those blocks. 

As noted earlier, the user-specified parameters are expressions that may be in the 
form of numerical values (e.g., "10"), variables defined as constants (e.g., "a" where a=10), 
interfaced variables (e.g., "a" ) or some combination thereof (e.g., a*b*sin(c)). The following 
examples are valid input for the gain parameter of the gain block, such as gain blocks 56 and 
60, as shown in FIG. 3. 



Gain: 1 . 5 



A scalar gain value. 

A gain value defined as an expression of the 

variables: a, b, and c. 

A 2x3 matrix of gain values. 

A vector of gain values 1,2,3, . . . , 1 00. 



Gain: a*b+c 



Gain: [1 2 3; 4 5 6] 



Gain: [1:100] 
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Gain: a * [ 1 : 1 0 0 ] A variable a multiplied by a vector of gain 

values 1,2,3, 100. 

As shown in FIG. 3, the gainl block 56 is implemented to use a block parameter 
defined as an expression 'a*b+c' (where a and b are constants, i.e., non-interfaced, and c is 
an interfaced variable therefore capable of being changed during model execution), whereas 
the gain2 block 60 is implemented to use a block parameter defined as a vector of gain values 
1,2,3, 100. 

In addition to the user-specified parameters (e.g., dialog parameters), the user also 
supplies to the module 20 a list of all interfaced variables used by the block methods. The 
list provided by the user designates a variable, for example, variable c in the gainl block 56, 
as interfaced and provides various attributes (data type, dimensionality, complexity, storage 
class, and so forth) for each variable designated as an interfaced variable. 

FIG. 4 is an exemplary block parameter dialog box 70 for the gain2 block 60 (of FIG. 
3). The dialog box 70 includes a first parameters field 72 for specifying a parameter value, in 
the example, a gain value or range of gain values. The dialog box 70 also includes a second 
parameters field 74 for specifying the type of gain multiplication, that is, element-wise or 
matrix-wise, to be performed by the gain2 block 60. 

The module 20, and more particularly, the block diagram processing engine 26, 
generates and supports the use of run-time parameters. Run-time parameters are the block 
parameters that are used during execution of the block diagram model or in generated code. 
They are derived from user-specified parameters. The run-time parameters can be the same 
as the user-specified parameters, but in many cases will be different. Whether there is a one- 
to-one correspondence between the dialog parameters and the run-time parameters wall 
depend on whether a block equation parameter expression "p" can be simplified for 
optimization, as will be discussed more fully below. 

FIG. 5 depicts a flow diagram of the operational flow of the module 20 and its 
internal components. Optionally, processing of the module 20 begins by enabling a user to 
create custom blocks (e.g., the S-function block 64 of FIG. 3) with run-time parameters (step 
80). If the user is using only the pre-packaged blocks provided by the module's library 24, or 
if all desired custom block definition is complete, the module 20, and more particularly, the 
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model editor 22, enables the user to construct a block diagram model using the blocks (pre- 
packaged, custom or combination of the two) (step 82). Once the model has been built (and, 
preferably, saved in memory), the module 20 invokes the block diagram processing engine 
26 (step 84). The block diagram processing engine 26 takes as inputs the graphical 
5 description of the model (that is, the blocks and lines) and processes those inputs by either 
executing the model or, alternatively, generating code that implements the model equations 
defined by the blocks of the block diagram model. Consequently, the module returns as 
output the results of the processing by the block diagram processing engine 86, more 
specifically, either simulation results if the model is executed (indicated in dotted lines by the 

10 reference numeral 88a), or the automatically generated code (indicated in dotted lines by the 
reference numeral 88b). The generated code can be deployed to a target application. 

Referring to FIG. 6, the operational flow of the block diagram processing engine 26 is 
shown. The engine 26 receives the user's block diagram model as an input (step 90) and 
compiles the block diagram of the block diagram model (step 92). The compiler phase 92 

15 determines the appropriate order of the blocks and transforms the graphical block diagram 
into a set of executable instructions (or operations). During this transformation, any invalid 
modeling specifications (such as an invalid parameter expression) are reported as errors and 
the compilation stops. A portion of the compiler phase 92 of the block diagram processing 
engine processing relates to processing of parameters 94 for parameter optimization and 

20 parameter expression mapping, as will be described. The engine 26 also includes a linker 
that, given the order of the equations as determined by the compiler phase 92, links and 
allocates appropriate working areas in memory to the equations (instructions) to enable 
execution of the model (run a simulation) or code generation code (step 96). The engine 26 
executes the model to produce simulation results (or, alternatively, generates executable 

25 code) (step 98). 

Referring to FIG. 7, the operation of the parameter processing portion 94 of the 
compiler phase 92 (hereinafter, parameter processor 94) is as follows. For each block in the 
block diagram, the parameter processor 94 evaluates the block's user- specified parameters 
(e.g., dialog box block parameters), if any (step 100). The evaluation determines numerical 

30 values of parameter expressions specified by the user (e.g., entered by the user in the dialog 
box parameter fields) and constructs a data structure to describe each parameter expression 
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that contains an interfaced variable. Thus, the data structure captures the interfaced, as well 
as any non-interfaced, variables for each user-specified parameter expression. Also, for each 
block in the block diagram, the parameter processor 94 sets up and maintains run-time 
parameters for the blocks (step 102). That is, the parameter processor 94 makes a call to the 
5 blocks to set up run-time parameters. In response, the blocks define run-time parameters, 
map the run-time parameters to the user-specified parameters and register the run-time 
parameters with the block diagram processing engine 26. The registration provides the 
engine 26 with information describing each blocks use of run-time parameters, e.g, the 
number of run-time parameters used, run-time parameter values and other attributes, as well 

1 0 as mapping information. 

Using the information from the evaluation and run-time parameter setup steps 1 00, 
102, respectively, all parameter attributes that are accessed by each block method can be 
collected and processed by the block diagram processing engine 26. More specifically, the 
parameter processor 94 pools together like run-time parameters that are non-interfaced, that 

15 is, remain constant during model execution or do not change in the generated code (step 
104). After parameter pooling, the parameter processor 94 creates a run-time parameter 
expression execution structure that allows interfaced variables in run-time parameter 
expressions to be accessed during model execution (e.g., for purposes of updating) or 
mapped to generated code (step 106). 

20 The parameter processing steps will be described in greater detail with reference to 

FIGS. 8-14. 

Referring to FIG. 8, a block data structure 1 10 used by the parameter processing 94 is 
shown. The block data structure 1 10 only illustrates those aspects of a block that pertain to 
parameters and parameter processing. Attached to the block data structure 1 1 0 are functions 

25 112 and 1 14 for evaluating dialog parameters ("EvalDialogParams()") and setting up runtime 
parameters ("SetupRuntimeParamsO"), respectively. In C, these ftmctions would be realized 
as function pointers within the block data structure 110. In C+H-, each of these functions 
would be a class method of the block class. The block data structure 110 further includes an 
internal data array 116 ("IntemalData"). The internal data array 116 includes the following: 

30 an array of abstract syntax trees (ASTs) 1 1 8, one for each block parameter field; an array of 
numerical values ("NumericDialogParamValues[nParams]") 120, which is an array of 
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numerical objects each representing the evaluated value of the block parameter expression; 
and an array of runtime parameters 122 ("RuntimeParams[nRunTimeParams]"). The 
runtime parameters array 122 is an array of parameters which are used by the block during 
execution. Also attached to the data structure 1 1 0 are various other methods or functions 
(used by the parameter processing 94), including a GetRuntimeParam method 124, which is 
used by the parameter pooling 104, as will be described. 

Referring to FIG. 9, details of the block parameter evaluation process 100 (from FIG. 
7) are shovra. The process 100 begins (step 130) by proceeding to the next unprocessed 
block (step 132). If there are no more blocks to be processed, the process 100 terminates 
(step 134). If there is at least one more block yet to be processed, the process 100 invokes 
the block EvalDialogParams() method 112 (shown in FIG. 8) (step 136). The method 112, 
once invoked, evaluates dialog parameters in parameter expressions to resolve those 
parameter expressions for their numeric values (step 136a). The results are stored in the 
NumericDialogParamValues[nParams] array 120 (from FIG. 8). This evaluation uses a 
workspace (shown as shaded block 137) where the variables as well as the expressions are 
defined. For example, if a parameter expression 'a*b+c', and the variable values are defined 
in the workspace as a=l , b=2 and c=3, the evaluation results in a value of 5. The invoked 
method 1 12 also creates an AST for any parameter expressions containing interfaced 
variables, collapsing nodes for any portion of a parameter expression containing non- 
interfaced variables for more efficient storage (step 136b). The method 1 12 uses a table of 
interfaced variables (shovm as shaded block 138) to determine the interfaced values. The 
table 138 shows a variable c as an interfaced variable. Thus, and referring to FIG. lOA, an 
AST 140 created for the block parameter expression 'a*b+c' , in which variable c is 
determined to be interfaced, A simplified version of the AST 1 10 is showoi in FIG. lOB as 
AST 142. The AST 142 is derived from the AST 1 10 by collapsing the non-interfaced nodes 
a and b of AST 1 10 into a single node representing the product a*b. In this example, if a=l 
and b=2, the resuh of multiplying the values of the variables a and b is the value '2'. 

Referring to FIG. 1 1, details of the runtime parameter setup process 102 (from FIG. 
7) are shovsm. The process 102 begins (step 150) by proceeding to the next unprocessed 
block (step 152). If there are no more blocks to be processing, the process 102 terminates 
(step 154). If there is at least one more block yet to be processed, the process 102 invokes 

12 
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the SetupRuntimeParamsQ method 1 14 (shown in FIG. 8) (step 156). The method 1 14 sets 
up the number of run-time parameters uses by a block (step 1 56a). The number of run-time 
parameters is a function of the number of dialog parameters and evaluated numeric values of 
the dialog parameters. The setup step 156a appropriately sizes the block's 
5 RuntimeParams[nRunTimeParams] runtime parameters data array 122 (shown in FIG. 8). 
The method 1 14, as invoked, also creates each run-time parameter and stores information 
defining the run-time parameter in the runtime parameters data array 122 (step 156b). The 
run-time parameter information includes a numerical value, a mapping back to the dialog 
parameters/parameter expression from which it was created, and the run-time parameter's 

10 characteristics (e.g., data type, numeric type (real vs. complex), whether or not the parameter 
is transforms (as will be later described), and dimensions. Other characteristics may be 
stored in association with the run-time parameter as well. 

Referring now to FIG. 12, the parameter pooling process 104 (from FIG. 7) begins 
(step 160) by creating an empty aggregated run-time parameter table (step 162). The 

15 aggregated run-time parameter table is shovra as shaded block 1 63. The process 104 
proceeds to the next unprocessed block (step 164). If there are no more blocks to be 
processing, the process 104 terminates (step 166). If there is at least one more block yet to be 
processed, the process 104 invokes the method GetRuntimeParam 124 (shovra in FIG. 8) 
(step 168) to examine each run-time parameter and perform parameter pooling to the extent 

20 possible. More specifically, if the process 168 determines that the run-time parameter does 
not map back to dialog parameters containing interfaced variables or if the run-time 
parameter has been explicitly marked as a constant (step 1 68a), the process/step 1 68 
performs the following steps. The process 1 68 computes a checksum of the numeric run- 
time parameter data and, using a hash function, determines if this value exists in the 

25 aggregated run-time parameter table (step 168b). If the run-time parameter does not exist in 
the aggregated run-time parameter table, it is added to the table (step 168c). If it already 
exists in the table, the process 168 frees the block's numeric run-time parameter data and 
updates the table entry indicating that this run-time parameter is pooled (step 168d). It sets 
the block's numeric run-time parameter data to be equal to the table entry (168e). In an 

30 alternative implementation, the aggregated run-time parameter table could be created as the 
dialog parameters were being processed. 
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Referring to FIG. 1 1, details of the execution structure setup process 106 (from FIG. 
7) are shown. The process 106 begins (step 170) by proceeding to the next unprocessed 
block (step 1 72). If there are no more blocks to be processing, the process 106 terminates 
(step 174). If there is at least one more block yet to be processed, the process 106 examines 
5 the block to determine if the block has a run-time parameter that maps back to a dialog 

parameter containing an interfaced variable and, if the block is a block that has such a run- 
time parameter, marks the block as such (step 176). During code generation, the structure of 
any block so marked is maintained by using the AST from the dialog parameter evaluation. 
During simulation, when the interfaced variable is changed, the corresponding numeric value 
10 of the run-time parameter is updated by re-evaluating the AST. 

The parameter processing steps 100, 102, 104, 106 will be further described in the 
paragraphs to follow. 

As discussed above, each of the blocks in the block diagram model is responsible for 
defining a mapping of run-time parameters (to be used by the block methods during model 

15 execution) to user-specified parameters. This mapping is registered with the block diagram 
processing engine 26 during the setup run-time parameters phase 1 02 of the parameter 
processing 94. The block diagram processing engine 26 works in conjunction with the 
blocks to manage the run-time parameters on behalf of the blocks. This management activity 
includes determining where to store the data for the run-time parameters and managing 

20 changes to parameters that occur during model execution (for example, to ensure block 

parameter integrity). The run-time parameter configuration methodology of the parameter 
processor 94 therefore enables blocks to rewrite their equations to achieve optimal 
realization. This rewriting can be done either statically, a priori to knov^ng parameter data 
values or dynamically after parameters data values become known or change. 

25 While a parameter is considered interfaced if the user has defined the parameter in 

terms of interfaced variables, a block can override that definition. That is, the block can 
explicitly specify that a parameter that includes a variable declared by the user to be 
interfaced is non-interfaced by specifying that the corresponding run-time parameter is a 
constant. This type of run-time parameter can be referred to as an explicit constant run-time 

30 parameter. 

The manner in which the blocks define run-time parameters and map run-time 
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parameters to dialog parameters will now be described. The blocks define a mapping 
function or method that maps from run-time parameters to the dialog parameters. For 
example, the output method, y = OutputMethod(t,x,u,p), for the S-function block 60 (of FIG. 
3) having three parameters (prml, prm2, and prm3) is defined to be: 

5 

y - prml + (prm2-prm3)*u 
This output method or equation can be rewritten internally by the block as 

10 y = rtprml + (rtprm2)*u 

where run-time parameters, 'rtprmT and 'rtprm2', are defined as 'prml' 
and 'prm2-prm3', respectively. 

The mapping function or method is called whenever the user changes the block 

15 parameters during model execution. The mapping of run-time parameters to dialog 
parameters can be any arbitrary function. 

The block registers its run-time parameter definitions with the block diagram 
processing engine 26. Fore example, the block may register that a parameter maps one-to-one 
with a dialog parameter (e.g., rtprml = prml). Alternatively, the registration could indicate a 

20 one-to-one mapping, but that the parameter is transformed, i.e., stored in a different data 

format. That is, a block can mark that its run-time parameter is transformed and tunable (i.e., 
interfaced). This block-level parameter specification allows the user to enter parameter 
information in a method that contains high-level abstractions, e.g., representing a real-world 
value by the using of a floating-point data type, as the block can convert it to a more efficient 

25 data store representation, e.g. an integer data type. The nodes of the AST that are specified as 
interfaced will be accessible in the generated code and will be represented by the efficient 
data storage representation. A transformed interfaced variable therefore has one 
representation in the block parameter specification and another representation in the 
generated code. 

30 An exemplary data structure for defining run-time parameters in the Simulink® 

context is as follows. 




15 
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#ifndef _SS_PARAM_REC 
# define _SS_PARAM_REC 
/* 

* Typedef for the enumeration that keeps track of the "transformed" 
5 * status of run-time parameters. 

*/ 

typedef enum { 
/* 

10 * The run- time parameter is not transformed if nDialogParamlndices is 

* one and there was no alteration of the dialog parameter 
*/ 

RTPARAM_NOT_TRANS FORMED = 0, 

15 /* 

* The run- time parameter is transformed if nDialogParamlndices > 1 or 

* there was an alteration of the dialog parameter value or data type. 
V 

RTPARAM_TRANSFORMED = 1, 

20 

/* 

* The run- time parameter can be marked as 'make transformed tunable' 

* if nDialogParamlndices is one and you altered the dialog parameter 

* value or data type. If the parameter field contains a single 
25 * tunable variable, say 'k', then the transformed data type, etc. 

* version of k will be used in the generated code. All references to 

* tunable parameters that have been transformed must be done so in 

* the same fashion, otherwise an error will be generated. 
V 

30 RTPARAM_MAKE_TRANSFORMED_TUNABLE = 2 

} TransformedFlag; 

typedef struct ssParamRec_tag { 

35 /* 

* The parameter characteristics 
*/ 

const char *name; /* Name of the parameter. This must point 

* to persistent memory. Do not set to a local 
40 * variable (static char name [32] or strings 

* "name" are okay) 
*/ 

int_T nDimensions ; /* Number of dimensions for this parameter */ 

int_T ^dimensions; /* Array giving the dimension (sizes) of 

45 * the paramter */ 

16 



Docket No.: 04899-060001 

DTypeld dataTypeld; /* For built-in data types, see BuiltlnDTypeld 

* in simstruc_types . h */ 
boolean_T complexSignal ; /* FALSE or TRUE */ 

/* 

* The data pointer. This is the data values for the run-time parameter. 

* Simulink needs this when creating the model. rtw file. Complex Simulink 

* signals are store interleaved. Likewise complex run- time parameters 

* must be stored interleaved. 

* Note that mxArrays store the real and complex parts of complex 

* matrices as two separate contiguous pieces of data instead of 

* interleaving the real and complex parts. */ 

void *data; 
/* 

* The data attributes pointer is a persistent storage location where the 

* user can store additional information describing the data and then 

* recover this information later (potentially in a different function) . 
*/ 

const void *dataAttributes 
/* 

* Run- time parameters to dialog parameter map. 
* 

* For proper interaction with 'tunable parameter variables' that 

* are set via the "Tunable Parameters Dialog", Simulink requires 

* information about how the run -time parameters are derived. 
* 

* It is an implicit assumption that all run- time parameters are derived 

* from the dialog parameters, i.e., ssGetSFcnParam (S, i) , Thus each 

* run-time parameter is derived from a subset of the dialog parameters: 

* run-time_parameter = some_funct ion (subset of dialog parameters). 

* In the simplest case, 

* run-time_parameter = a specific dialog parameter 

* The following information specifies which dialog parameters are 

* used in deriving a specific run- time parameter. For the simplest case, 

* we have 

* nDialogParamlndices = 1,- 

* dialogParamlndices = k; 

* transformed = false; 

* This case is important to identify because this will allow for 

* efficient and correct code generation of r\an-time parameters when they 

17 
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* map directly back to tunable parameter variables specified in 

* the 'Tunable Parameters Dialog' . 
*/ 

int_T nDlgParamlndices; 
int_T *dlgParamIndices ; 



Trans formedFlag transformed; 
boolean_T output AsMatrix; 

} ssParamRec ; 
#endif 

The mapping information (ssParamRec->nDlgParamIndices, 
ssParamRec->nlgParamInciices) is used in setting up the expression mapping of the 
interfaced variables. In creating the run-time parameter, an initial value is specified 
(ssParamRec->data). The initial value is used in parameter pooling step. 

As mentioned above, parameter pooling only applies to the constant run-time 
parameters. A run-time parameter is designated as constant if either of the following 
conditions hold: i) the run-time parameter does not map back to a dialog parameter that 
contains an interfaced variable; or ii) the run-time parameter is explicitly declared as constant 
by the block (as discussed earlier). 

Generally, the parameter pooling step 1 04 identifies block parameters having 
parameter.data that matches a given criterion, and allocates only one copy of the parameter 
data for all references to a given parameter data set. The criterion can require that the data 
match bit-for-bit. Parameter pooling that uses such an "exact data match" matching criterion 
is referred to herein as "uniform parameter pooling". Alternatively, the criterion can require 
that the data match exactly (i.e., bit-for-bit) only after a mapping function has been applied to 
the data. This latter type of parameter pooling is referred to herein as "non-uniform 
parameter pooling." Consequently, when non-uniform parameter pooling is employed, a 
block reconstructs the parameter data it needs for execution from the pooled parameters by 
|the mapping function during execution. 

The uniform parameter pooling requires an identical data matching. If the values of 

18 




/* Array of length nDialogParamlndices 

* indicating the dialog parameters that 

* are used in deriving the run- time 

* parameter */ 
/* Transformed status */ 

/* Write out parameter as a vector (false) 

* [default] or a matrix (true) 
V 
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the constant run-time parameters are bit-for-bit the same, then the block diagram processing 
engine 26 creates one memory location for the run-time parameter references. This memory 
location is referred to as a pooled parameter. The uniform parameter pooling looks for all 
registered run-time parameters with the same value and other attributes (i.e., data type, 
dimension, and so forth) and combines them into one run-time parameter in one location. 

Non-uniform parameter pooling occurs when a one-to-one function is used to match 
data. The block is responsible for registering the data-matching function with the block 
diagram processing engine 26 during run-time parameter setup. The block diagram 
processing engine 26 may also have a set of predefined data-matching functions. The block 
diagram processing engine 26 is responsible for invoking these data-matching functions on 
the run-time parameters to see if the run-time parameters are identical. For example, suppose 
that a first block A is using a first constant run-time parameter l : 100, a vector of length 100 
with values 1, 2, 100, and a second block B is using a second constant run-time parameter 
2 : 2 : 1 0 0, a vector of length 50 with values 2, 4, . . . , 1 00. A data matching function takes the 
two constant run-time parameters as input arguments and returns true (success) if it finds a 
mapping between the two parameters. One of the arguments, say a first argument 
(my_rt_prm), is the run-time parameter of block B and the other argument, say a second 
argument (rt_prm), is a potential constant run-time parameter, such as the run-time 
parameter of block A, with which the block B may be pooled. 

Suppose that block B defines the data matching fianction to be as follows: 

Pmap (iny_rt_prin, rtprm) 

If (DataElementTypesMatch (my_rt_prni, rtprm) ) and 

AnIndexExistsThatMapsBetweenPrms (my_rt_prm, rtprm) ) then 
Return true; 
Else 

Return falser- 
End Pmap; 

The function DataElementTypesMatch ensures that the function is examining 
constant run-time parameters of the same data type (e.g., both IEEE double precision 
floating-point numbers). The fimction, AnindexExistsThatMapsBetweenPrms looks for an 

19 
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indexing operator that can recover my_r t_prin from the rt_prm. For this example, the 
indexing operator is the value 2, because block B's constant run-time parameter equals block 
A's constant run-time parameter at every other point. 

If the block diagram processing engine 22 generates code from the model, the 
5 generated code conforms to the definitions of interfaced variables supplied by the user and all 
constant run-time parameters are pooled together. 

Referring back to the parameter processing step 106 (of FIG. 7), the execution 
structure allows parameter expressions with explicitly interfaced variables to be mapped to 
generated code. As mentioned before, a parameter can be an expression of numeric values, 

10 variables, and functions. Furthermore, some of parameter expression variables can be 
designated as interfaced variables, either in accordance with the user specification or as 
specified explicitly by the block when run-time parameters are defined. The purpose of 
interfaced variables is to provide the execution framework with a way to access and modify 
interfaced variables used by any number of blocks in the block diagram. The execution 

15 structure allows for a one-to-one mapping of variables in a parameter expression to support 
different host/target representations. The expression mapping methodology can be extended 
to cover transformed interfaced variables as well. Therefore, the expression mapping 
provides a means by which user marked variables within parameter expressions can be 
accessed and modified during simulation or within the automatically generated code for the 

20 block diagram. 

The techniques of parameter optimization, pooling and expression mapping are 
further illustrated for the bdexample (model 52 of FIG. 3) in code produced by The 
Simulink/Real-Time Workshop (which corresponds to the block diagram processing engine 
26), as shovm in the Appendix. 

25 The exact mechanism by which the blocks map their equations to generated code is 

not central to the concept of parameter processing as described herein. The Simulink 4 and 
the Real-Time Workshop 4 products by The Math Works Inc. use a text processing utility to 
transform the block source code to the required output. Of course, other implementations are 
possible. For example, the blocks could have methods that produce the output equations in 

30 ASCII form that is suitable for placement in the generated code. 

The parameter processing techniques as thus described enable users to solve a wide 
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range of problems. Users benefit from the parameter pooling and expression mapping by 
using pre-packaged blocks provided with the Simulink® tool or blocks available from third 
parties. Users also are able to extend the tool by defining their own blocks to work 
seamlessly with the block diagram tool to achieve the benefits of parameter pooling and 
expression mapping. 

During code generation, the blocks provide information about how the generated code 
should look. In the case of the S-function block example, a file defining the format of the 
block output is as follows: 

% implements "sfun_runtime_opt'* "C" 

%% Function: mdlOutputs ======================================================= 

%% Abstract: 
%% 

%% y = rtprml + rtprm2 * u 

%% 

%function Outputs (block, system) Output 
/* %<Type> Block: %<Name> */ 

{ 

%assign rollVars = ["U", "Y", "P"] 

%roll sigldx = RollRegions, lev = 5, block, "Roller", rollVars 
%assign u = LibBlocklnputSignal (0, "", lev, sigldx) 

%assign y = LibBlockOutputSignal { 0, lev, sigldx) 

%assign rtprml = LibBlockParameter (rtprml, "", lev, sigldx) 
%assign rtprm2 = LibBlockParameter ( rtprm2 , lev, sigldx) 

%<y> = %<rtprml> * %<rtprm2> * %<u>; ^ How to format the output equation 
%endroll 

} 

%endf unction 

It is to be understood that while the invention has been described in conjunction with 
the detailed description thereof, the foregoing description is intended to illustrate and not 
limit the scope of the invention, which is defined by the scope of the appended claims. Other 
embodiments are within the scope of the following claims. 
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APPENDIX 

Executable code produced by The Simulink/Real-Time Workshop for the example 
'bdexamplel" is as follows: 

/* 

■* bdexamplel . c 

* Real-Time Workshop code generation for Simulink model "bdexamplel .mdl" . 



10 



Model Version 

Real-Time Workshop file version 
Real-Time Workshop file generated on 
TLC version 

C source code generated on 



1.23 

4.0 $Date: 2000/09/19 19:45:27 $ 

Sun Jul 01 23:51:00 2001 

4.0 (Aug 21 2000) 

Sun Jul 01 23:51:00 2001 



15 



Relevant TLC Options: 
InlineParameters 
RollThreshold 
CodeFormat 



= 1 

= 5 

= RealTime 



20 



25 



Simulink model settings: 



* Solver 

* StartTime 

* StopTime 

* FixedStep 
*/ 



FixedStep 
0.0 3 
10.0 s 
0.2 s 



30 



# include <math.h> 

#include <string.h> 

#include "bdexamplel .h" 

#include "bdexamplel_prm. h" 



/* Start of Functions in model "bdexamplel" */ 



35 



/* Start the model */ 
void MdlStart (void) 



/* (no start code required) */ 



40 



45 



/* Compute block outputs */ 
void MdlOutputs (int_T tid) 
{ 

/* local block i/o variables */ 
real_T rtb_temp0 [ 100] ; 
real_T rtb_templ t 100] ; 



22 
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/* Sin Block: <Root>/Sine Wave */ 
{ 

int_T il; 

real_T *yO = &rtb_tempO [0] ; 
5 const real_T *p_Amplitude = &rtP.pl[0]; <- example of a pooled parameter 

const real_T *p_Frequency ~ &rtP.pl[0]; example of a pooled parameter 

for (il=0; il < 100; il++) { 
10 yO[il] = (p_Amplitude[il] ) * sin ( {p_Frequency [ il ] ) * ssGetT{rtS) + (0.0)), 



/* Gain Block: <Root>/Gainl */ 
{ 

int_T il; 

const rGal_T *uO = &rtb_tempO [0] ; 
real_T *yO = &rtb_templ [ 0] ; 

20 for {il=0; il < 100; il++) { 

yO[il] = u0[il] * (1.0 * 2.0+c); <- example of expression mapping: c is 

preserved 

} 



} 



/* Gain Block: <Root>/Gain2 */ 
{ 

int_T il; 

const real_T *uO = &rtb_templ [ 0] ; 
30 real_T *yO = &rtb_templ [0] ; 

const real_T *p_Gain = &rtP.pltO]; <- example of a pooled parameter 

for (il=0; il < 100; il++) { 

y0[il] ^ uO[il] * (p_Gaintil] ) ; 

35 } 

} 

/* Lookup Block: <Root>/Look-Up Table */ 
{ 

40 int_T il; 

const real_T *uO = &rtb_tempO [ 0] ; 
real_T *yO = &rtb_tempO [0] ; 

for {il-0; il < 100; il+-f) { 

45 yO[il] = rt_Lookup(&rtP.Look_Up_Table_XData[0) , 
100, 
uO[il] , 
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&rtP.pl[0]); ^ example of a pooled parameter 

} 

) 

/* Sum Block: <Root>/Sum */ 
{ 

int_T il; 

const real_T *uO = &rtb_templ [ 0] ; 
const real_T *ul - &rtb_tempO [ 0] ; 
real_T *yO = &rtb_templ [0] ; 

for (il=0; il < 100; il++) { 
yO[il] = uO[il] + ul[il] ; 

} 

} 

/* S-Function Block.: <Root>/S-Functionl */ 
{ 

{ 

int_T il; 

const real_T *uO = &rtb_templ [ 0] ; 
real_T *yO = &rtb_templ [ 0] ; 

const real_T *p_rtprm2 = &rtP . S_Functionl_rtprm2 [ 0] ; ^ example of parameter 

optimization 

for (il=0; il < 100; il++) { 

yO[il] = (5.0) * {p_rtprm2 [il] ) * uO[il]; 

} 

} 

} 

/* Outport Block: <Root>/Outl */ 
{ 

int_T il; 

real_T *yO - &rtY . Outl [0] ; 

const real_T *uO = &rtb_templ [0] ; 

for (il=0; il < 100; il++} { 
yO [il] = uO[il] ; 

} 

} 

} 

/* Perform model update */ 
void MdlUpdate (int_T tid) 
{ 
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/* (no update code required) */ 

} 

/* Terminate function */ 
void MdlTerminate ( void) 
{ 

/* (no terminate code required) */ 

} 

/* End of Functions in model "bdexamplel" */ 
#include "bdexamplel_reg . h" 
/* [EOF] bdexamplel. c */ 

In a generated header file, the block diagram parameters data structure is defined to 

be: 

typedef struct Parameters_tag { 

real_T pi [100]; /* Expression: a* (1:100) 

* External Mode Tunable: no 

* Referenced by blocks: 

* <Root>/Sine Wave 

* <Root>/Sine Wave 

* <Root>/Gain2 

* <Root>/Look-Up Table 
*/ 

real_T Look_Up_Table_XData [ 100] ; /* Expression: -1:2.01/100:1 

* External Mode Tunable: no 

* Referenced by block: 

* <Root>/Look-Up Table 
V 

real_T S_Functionl_rtprm2 [ 100] ; /* Computed Parameter: rtprm2 

* External Mode Tunable: no 

* Referenced by block: 

* <Root>/S-Functionl 
*/ 

} Parameters; 

In this example, the S-function block implements the output equation, 

output = prml * (prm2-prm3) *input_signal 

and the implementation uses run-time parameters where the first run-time parameter 
(rtprmi) equals prml and the second run-time parameter (rtprm2) equals prm2-prm3, 
giving: 

25 



output = rtprml * ( rtprm2 ) * input_signai 





The source code for this S-function is as follows: 




/* 


$Revision: 1.1 $ */ 


5 


/* 






* 


File : sf un_runtime_opt . c 




* 


& Vi Q 1" T" 3 r" 1" ■ 






Illustration of run-time parameter optimization where the 




* 
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prml: a scalar or a vector of length N 




*• 


prm^ , a scaxar ox a vector or renytn w 




* 


prm3: a scalar or a vector of length N 


15 




the output equation is defined as: 






y = prml + (prm2-prm3 ) *u 




* 
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and reduce memory, this equation can be written as: 




■k 
* 


y = rtprml + (rtprm2)*u 




* 


where the run-time parameters are defined to be: 


25 


★ 








rtprml = prml 




* 
* 


rtprm2 = prm2-prm3 




* 


In this example, these parameters are 'fixed' during model exection 


30 


* 


This means there is no need for the mdlProcessParameters function. 




* 


/ 



#define S_FUNCTION_NAME sf un_runtime_opt 
#define S_FUNCTION_LEVEL 2 

35 

#include <string.h> 
#include "tmwtypes.h" 
#include "simstruc.h" 

40 

#define PRM1_IDX 0 

#define PRM1{S) ssGetSFcnParam (S, PRM1_IDX) 

#define PRM2_IDX 1 
45 #define PRM2(S) ssGetSFcnParam (S, PRM2 IDX) 
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#define PRM3_IDX 2 

#define PRM3(S) ssGetSFcnParara ( S, Piyyi3_IDX) 
#define NPARAMS 3 

/* Function: mdlini tializeSizes -=====-========^=====:==:==========^============== 

* Abstract: 

* Call radlCheckParameters to verify that the parameters are okay, 

* then setup sizes of the various vectors. 

static void mdllnitializeSizes (SimStruct *S) 
{ 

int vectLen; 

ssSetNumSFcnParams (S, NPARAMS) ; <- Block requires three dialog parameters 
#if def ined (MATLAB_MEX_FILE) 

if (ssGetNumSFcnParams (S) != ssGetSFcnParamsCount (S) ) { 

return; /* Parameter mismatch will be reported by Simulink */ 

} 

#endif 

ssSetSFcnParamTunable (S, PRM1_IDX, false) ; 
ssSetSFcnParamTunable (S, PRM2_IDX, false) ; 
SsSetSFcnParamTunable (S, PRM3_IDX, false) ; 

ssSetNumContStates (S, 0) ; 
ssSetNumDiscStates (S, 0) ; 

/* 

* Determine the maximiam parameter vector length. 

* This will be the input/output width. Note the 

* input can be scalar expanded: 

* u > block > y 

* length (u) == 1 or vectLen 

* length (y) == vectLen. 
V 

{ 

int_T i; 
vectLen = 1; 

for (i - 0; i < NPARAMS; i++) { 

const mxArray *mx = ssGetSFcnParam (S, i ) ; 

int nEls = mxGe tNumber Of Elements (mx) ; 

if (nEls > 1) ( 

vectLen = nEls; 
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break; 



if ( ! ssSetNumlnputPorts (S, 1)) return; 
ssSetlnputPortWidth (S, 0, vectLen) ; 
ssSetlnputPortDirectFeedThrough (S, 0, 1); 
ssSetlnputPortOverWritable (S, 0, 1); 
10 ssSetlnputPortReusable (S, 0, 1); 

ssSetlnputPortRequiredContiguous (S, 0, 1); 

if { ! ssSetNumOutputPorts (S, 1)) return; 
ssSetOutputPortWidth (S, 0, vectLen); 
15 ssSetOutputPortReusable(S, 0, 1); 

ssSetNumSampleTimes (S, 1); 
ssSetNumRWork (S, 0); 
ssSetNumIWork(S, 0) ; 
20 ssSetNumPWork(S, 0); 

ssSetNumModes (S, 0}; 
ssSetNumNonsampledZCs (S, 0); 

/* Take care when specifying exception free code - see sfuntmpl.doc */ 
25 ssSetOptions (S, (SS_OPTION_EXCEPTION_FREE_CODE | 

S S_OPT I ON_ALLOW_I NPUT_SCALAR_EXPAN S I ON | 
SS_OPTIGN_USE_TLC_WITH_ACCELERATOR | 
S S_0 PT I ON_C ALL_TERM I N ATE_ON_EX I T 1 
SS_0PTION_ALL0W_INPUT_SCALAR_EXPANSI0N) ) ; 

30 

} /* end mdllnitializeSizes */ 

/* Function: itidllnitializeSampleTimes ==============:===========^=========== 

* Abstract: 

35 * specif iy that we inherit our sample time from the driving block. 

static void mdllnitializeSampleTimes (SimStruct *S) 
{ 

ssSetSampleTime(S, 0, INHERITED_SAMPLE_TIME) ; 
40 ssSetOf fsetTime(S, 0, 0.0); 

} 

#define MDL_SET_WORK_WIDTHS /* Change to #undef to remove function */ 
#if defined (MDL_SET_WORK_WIDTHS) && def ined (MATLAB_MEX_FILE) 
45 /* Function: mdlSetWorkWidths =================^=====-====================== 

* Abstract: 

* Set up run-time parameters. 
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V 

static void mdlSetWorkWidths ( SimSt ruct *S) 
{ 

if { ! ssSetNumRunTimeParams (S, 2)) return; ^ register during nin-time set-up phase 
that two parameters are needed 



ssParamRec rtprml; 

int_T dlgParamlndex - PRM1_IDX; 

int_T dim = mxGetNumberOf Elements (PRMl (S) ) ; 



rtprml . name 
rtprml . nDimensions 
rtprml . dimensions 
rtprml . dataTypeld 
rtprml . complexSignal 
rtprml . data 
rtprml . dataAttributes 
rtprml . nDlgParamlndices 
rtprml . dlgParamlndices 
rtprml . transformed 
rtprml . outputAsMatrix 



= "rtprml"; 

= 1; 

= &dim; 

= SS_DOUBLE; 

= COMPLEX_NO; 

= (void *}mxGetPr (PRMl (S) ) ; 
= NULL; 
= 1; 

= &dlgParamIndex; 
= false; 
= false; 



if ( ! ssSetRunTimeParamInf o (S, 0, Srtprml)) return; ^ register the first r\in- 
time parameter as equal to the first dialog parameter (prml) . 

} 
{ 

ssParamRec rtprm2; 



real_T 


*prm2 


= mxGetPr (PRM2 (S) ) ; 




int_T 


nEls2 


= mxGetNumberOf Elements ( ssGetSFcnParam { S, PRM2_ 


_IDX) ) 


int_T 


inc2 


= (nEls2 > 1) ; 




real_T 


*prm3 


= mxGetPr {PRM3 (S) ) ; 




int_T 


nEls3 


= mxGetNumberOf Elements ( ssGetSFcnParam ( S , PRM3_ 


.IDX) ) 


int_T 


inc3 


= (nEls3 > 1); 





int_T nEls = nEls2 > nEls3? nEls2: nEls3; 

real_T *buf = malloc (nEls*sizeof (buf [0] ) ) ; 

int_T dlgParamlndices [2] ; 

int_T i; 



if (buf == NULL) { 

ssSetErrorStatus (S, "memory alloc error in sf un_runtime_opt" ) ; 
return; 

} 
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for (i =0; i < nEls; { 
buf[i] ~ *prm2 - *prm3; 
prm2 += inc2; 
prm3 += inc3; 

) 

dlgParamlndices [0] - 2; 
dlgParamlndices [1] = 3; 
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rtprm2 . name 
rtprm2 . nDimensions 
rtprm2 . dimensions 
rtprm2 . dataTypeld 
rtprm2 . complexSignal 
rtprm2 . data 
rtprm2 . dataAttributes 
rtprm2 . nDlgParamlndices 
rtprm2 . dlgParamlndices 
rtprm2 , transformed 
rtprm2 . outputAsMatrix 



"rtprm2 " ; 
1; 

snEls; 
SS_DOUBLE; 
COMPLEX_NO; 
(void *)buf; 
NULL; 
2; 

dlgParamlndices ; 

true; 

false; 
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if ( ! ssSetRunTimeParamInf o { 1, &rtprm2)) { ^ register the second dialog 
return; paramerer equal to the dialog 

} parameters: prm2-prm3. 

} 
} 

#endif /* MDL SET WORK WIDTHS */ 
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/* Function: mdlOutputs 
* Abstract: 



y = rtprml + (rtprm2)*u 
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*/ 

static void mdlOutputs (SimStruct *S, int_T tid) 
{ 



int_T 
int_T 
int T 



el; 

uWidth 
uinc 
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const real_T *u 
int__T yWidth 
real_T *y 
const real_T *rtprml 
int_T incl 
const real_T *rtprm2 
int T inc2 



ssGetlnputPortWidth (S, 0) ; 
(uWidth > 1) ; 

ssGetlnputPortRealSignal (S, 0) ; 
ssGetOutputPortWidth ( S , 0 ) ; 
ssGetOutputPortRealSignal (S, 0) ; 

(const real_T * ) ssGetRunTimeParamInf o (S, 0) ->data; 
ssGetRunTimeParamlnfo (S, 0) ->dimensions [0] > 1; 
(const real_T * ) ssGetRunTimeParamInf o (S, 1 ) ->data; 
SsGetRunTimeParamlnfo (S, 1) ->dimensions [0] > 1; 
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* Generate sum and if needed average. 

for (el = 0; el < yWidth; el++) { 

*y++ = *rtprinl + (*rtprm2) * (*u); ^ Use run-time parameters in output method 

u += uinc; 
rtprml += incl; 
rtprin2 += inc2; 

} 

} /* end mdlOutputs */ 

/* Function: mdlTerminate ^===============^========================:============ 

* Abstract: 

* Free the 2nd run-time parameter data because it was allocated by 

* this block (i.e., not a direct map to dialog parameters). 
V 

static void mdlTerminate (SimStruct *S) 
{ 

if (ssGetNumRunTimeParams (S) 2 && 

ssGetRunTimeParamlnfo (S, 1) != NULL && 
ssGetRunTimeParamInf o (S, 1 ) ->data != NULL) { 
free (ssGetRunTimeParamlnfo (S, 1) ->data) ; 

} 

) 

#ifdef MATLAB_MEX_FILE 
#include "simulink.c" 
#else 

#include "cg_sfun.h" 
#endif 




/* Is this file being compiled as a MEX-file? */ 
/* MEX-file interface mechanism */ 

/* Code generation registration function */ 
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